The preferred embodiment of the present invention is particularly directed to a method and system for optimizing the termination of programmable or directly or indirectly computer-controlled test equipment, for performing a variety of tests on a device under test. Equipment may be controlled indirectly by screen or other prompts to a human operator to change equipment states. In such systems, a piece of equipment, such as a power supply, as well as the linkage between the equipment and the device under test, are referred to as "devices" as contemplated herein. Depending upon the tests to be performed, various sets of devices are coupled to each other and the device under test in order to perform various tests on it.
The present invention, however, may be practiced in any general system that uses a plurality of devices in a combination or set to perform a test or operation. Thus, the concept may be used to control fluid flow systems where different combinations of fluid paths exist or other such system control applications.
Systems of programmable devices, such as test instruments, signal routing devices, and devices-under-test, including devices controlled directly by signals from a computer or by human operators according to directions displayed or otherwise presented by a computer according to a software program (test program) running on a computer, are often written as a compromised attempt to address several issues: total test time, test system wear, test module positional flexibility within a test program and portability among test programs and test systems, and operator, test system, and device-under-test safety.
In most test situations, total test time is to be minimized: the shorter the time required to examine a device-under-test, the more devices that can be tested. At the same time, it is desirable that an activity that tends to wear out mechanical parts of the test system be eliminated. The phenomenon known as cycling is typically the major cause of longer test times and mechanical wear.
Test instruments and signal paths experience cycling as different groups of these devices are called into or released from use. Cycling is the repeated turning on and turning off of a signal source or destination device, or the making and breaking of a signal path between two devices, for example, through a switch matrix. Cycling is the major cause of wear and failure when devices implement their on/off control with mechanical parts. Cycling also takes time to initiate and complete and thus reduces the rate at which measurements can be made and devices-under-test can be tested.
Test programs are often written to consist of modular test or measurement procedures (test modules). Modular, here, means independence from both a test program's history and its future. That is, a test module is written in such a way that it does not depend on the execution of a previous or a next test module.
Modularity confers several benefits. When truly modular, the sequence in which test modules are executed in a test program can be altered without changing the internal structure of any module. This positional modularity allows test modules to be re-ordered, for example, to run tests that detect frequent device-under-test failures early and thus reduce total test time. Modularity can also permit test modules to be used not only in different test programs written in a compatible style but also in test programs run on different but compatible test systems. This portable modularity allows tests to be run in isolation, for example, to analyze the behavior of a device-under-test in the specific circumstance created by the test module. Portable modularity can also reduce test programming costs by eliminating the need to re-create existing test modules when new test programs must be written.
Test programmers must address problems of safety. To address ordering safety, they must arrange for their test modules to turn devices on and off in sequences that will avoid damage to other devices. For example, a signal path should be broken after a source device turns off to prevent the signal path switches from arcing. Power to the SHUNT winding of an electric motor should be turned off before power to the ARMATURE winding to prevent the motor from turning faster than its design limits. To address hazard safety, programmers must provide ways to protect system devices, devices under test, and test system operators from suddenly occurring hazardous conditions by quickly shutting down all instruments that are on. "Shutting down" is equivalent to returning to what may be considered a safe, benign or quiescent state.
Test programmers can use various techniques to address these issues, but the common approaches compromise in one or more areas to achieve gains in another.
In the simplest solution, test modules are written to achieve perfect positional and portable modularity and order safety by sacrificing test time and equipment wear to cycling and ignoring hazard safety. Here, each test module is written to turn on the devices it requires in a safe order (order safety), perform the test, and turn off the devices in a safe order. A problem--in this case hazard safety--is said to be ignored by a technique when the technique plays no role in its solution, even though it may be addressed by other means.
Two solutions allow test programmers to optimize their programs with respect to cycling by sacrificing modularity and ignoring hazard safety.
Using command-pair removal, a programmer can selectively remove pairs of off and on commands that control a device from the interiors of a fixed sequence of test modules leaving a minimal number of safely ordered on and off commands. The remaining code thus reflects the assumption that once the device has been turned on it will stay on. This approach severely restricts a test module's positional modularity and destroys its portable modularity. For example, if a first test module is moved to run after a second test module, and the test modules have been modified to reduce the amount of cycling, the program would not work properly unless deleted code was reinstated to both modules. The test modules, thus, depend on a specific execution history and anticipate a specific execution future.
Using special-case checking, test modules can reduce cycling to a minimum, provide limited positional modularity, and insure order safety. Special-case checking destroys portable modularity and ignores hazard safety. When a test module can be executed with a plurality of possible execution histories - different sets of devices left on - special-case checks can determine which test module was executed previously and control devices accordingly. These checks allow a limited number of specific execution histories and, thus, make a module insensitive to small positional changes of its predecessors. Conversely, it allows predecessor modules to change their position as long as the move has no effect on the future module. Most changes in modular order or addition or removal of modules force at least re-analysis of each special-case check. Test modules with special case checks depend on a specific set of execution histories and typically anticipate a specific execution future.
Two techniques are available that require no specific execution history but rather deal with all possible execution histories. In the off-list technique, cycling is reduced to minimum and positional modularity is achieved. Portable modularity and order safety are compromised, and hazard safety is ignored. Each test module provides a list of all test system devices that must be off before the module can begin its work - the off-list. The test module itself or a test system utility procedure tells each device represented in the list to turn off. By leaving selected devices out of the list, those devices can be left on if they were already on. The test module then proceeds to turn on the devices it needs, redundantly turning on those that were left on, and performs the test. If the off-list is structured to safely turn off devices based on a specific history, the module loses its positional modularity. If the list is not ordered for a specific history, it cannot guarantee that devices left on by a previous module will be turned off in a safe order. Test modules with off-lists are not directly portable to test systems that include different devices since those devices are not represented in the module's off-list but may have been left on by a previous test module. The off-list technique allows test modules to deal with all possible execution histories, ignore impact on the execution of future modules, and requires that they know all devices in the test system on which they execute.
In the on-list technique, cycling is reduced to a minimum, positional and portable modularity and hazard safety are achieved, but complete order safety is not possible. Each test module provides a list of all test system devices it will turn on and leave on. Then, a test system utility procedure can turn off every device known to the test system that is not in the on-list. By placing the responsibility of knowing all devices in the test system on the test system utility, the test module becomes portable. By providing a list of devices that are on or will be turned on, a hazard safety procedure can quickly turn off these devices if the need arises. This list can be safely ordered to turn off devices in a correct order even in a hazardous situation. The technique does not completely address order safety, however. When the test system utility compares its list of devices with those in a module's on-list, it has no way of knowing the order in which it should turn off devices that are not in the test module's on-list. The on-list technique allows test modules to deal with all possible execution histories, ignore impact on the execution of future modules, and ignore the presence of test system devices they do not use.
There remains, therefore, a need for a method and system that will allow test modules to be written in a way that reduces test execution time and test system wear by reducing cycling, is modular with respect to position in a test program and portable to other compatibly written test programs and test systems, that provides order safety with respect to other devices in the test system, and that assists a hazard safety test program subsystem by providing a safely ordered list of devices in a test system that are currently turned on.